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(57) Abstract: There is disclosed a technique of providing message authentication in a communication system comprising the steps 
of: transmitting a first message firom a first device to a second device; transmitting a second message from the second device to 
the first device, the second message including a message authenucation code detennined using said first and second messages; 
transmitting a third message from the first device to the second device, the third messages including a message authentication code 
determined using the third message. The message authentication code of the third message may be additionally based on the second 
or the second and first messages. 
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MESSAGE AUTHENTICATION 

FIELD OF THE INVENTION 

5 The present invention generally relates to a method for checking 

the integrity of messages in a communication system, particularly but not 
exclusively between a mobile station and a cellular network. 

BACKGROUND OF THE INVENTION 

All telecommunication . is subject to the problem of how to make 

10 sure that the information received has been sent by an authorized sender 
and not by somebody who is trying to masquerade as the sender. The prob- 
lem is particularly evident in cellular telecommunication systems, where the 
air interface presents a potential platform for eavesdropping and replacing 
the contents of a transmission by using higher transmission levels, even from 

15 a distance. A basic solution to this problem is the authentication of the com- 
municating parties. An authentication process aims to discover and check 
the identity of both the communicating parties, so that, each party receives 
information about the identity of the other party and can rely on the identifi- 
cation to a sufficient degree. Authentication is typically performed in a spe- 

20 cific procedure at the beginning of a connection. However, this does not 
adequately protect subsequent messages from unauthorized manipulation, 
insertion, and deletion. Thus, there is a need for the separate authentication 
of each transmitted message. The latter task can be carried out by append- 
ing a message authentication code (MAC-I) with a particular value to the 

25 message at the transmitting end and checking the MAC-I value at the re- 
ceiving end. 

A MAC-I is typically a relatively short string of bits based in some 
specified way on the message it protects and on a secret key known both by 
the sender and by the recipient of tiie message. The secret key is generated 
30 and agreed on typically in connection with the authentication procedure at 
the beginning of the connection. In some cases the algorithm that is used to 
calculate the MAC-I based on the secret key and on the message may also 
be secret. 

The process of authentication of single messages is often called 
35 integrity protection. To protect the integrity of signaling, the transmitting party 
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computes a MAC-I value based on the message to be sent and the secret 
key using the specified algorithm, and sends the message with the MAC-I 
value. The receiving party recomputes a MAC-I value based on the message 
and the same secret key according to the same specified algorithm, and 
5 compares the received MAC-I and the calculated MAC-I. If the two MAC-I 
values match, the recipient can trust that the message is intact and has been 
sent by the authorized party. 

Known integrity protection schemes are not completely reliable. A 
third party can attempt to manipulate a message transmitted between a first 
10 and a second party. There are two main alternative methods for forging a 
MAC-I value for a modified or a new message: obtaining the secret key; or 
by trying directly without the secret key. 

The secret key can be obtained by a third party in two ways: 
I) by computing all possible keys until a key is found matching the 
15 data of observed message MAC-I pairs, or by othenwise breaking the algo- 
rithm for producing MAC-I values; or ii) by directly capturing a stored or 
transmitted secret key. 

The original communicating parties can prevent a third party from 
obtaining the secret key by using an algorithm which is cryptographlcally 
20 strong and which uses a secret key which is long enough to prevent the 
exhaustive search of all keys, and by using other security means for the 
transmission and storage of secret keys. 

A third party may try to disrupt the sending of messages between 
the two parties without a secret key by guessing the correct MAC-I value, or 
25 by replaying some earlier message transmitted between the two parties for 
which message the correct MAC-I is known from the original transmission. 

Guessing of the con-ect MAC-I value can be made difficult by using 
long MAC-I values. The MAC-I value should be long enough to reduce the 
probability of conrect guessing to a sufficiently low level compared to the 
30 benefit gained by one successful forgery. For example, using a 32 bit MAC-I 
value reduces the probability of a con-ect guess to 1/4294967296, which is 
small enough for most applications. 

Obtaining a con-ect MAC-I value using the replay attack, i.e. by re- 
playing an earlier message, can be prevented by introducing a varying pa- 
35 rameter to the calculation of the MAC-I values. For example, a time stamp 
value, a sequence number, or a random number can be used as further input 
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to the MAC-I algorithm, in addition to the secret integrity key and the mes- 
sage. In the following, the prior art methods are described in more detail. 

When using sequence numbers, each party has to keep track of 
which sequence numbers have already been used and are not acceptable 
5 any more. The easiest way to implement this is to store the highest se- 
quence number used in MAC-I calculations so far. This approach has the 
drawback that between connections each party must maintain state informa- 
tion which is at least to some level synchronized. That is, they need to store 
the highest sequence number used so far. This requires the use of a large 

10 database in the network. 

A further approach is to include, a random number in each mes- 
sage, which the other side must use in MAC-I calculation the next time a 
message is sent for which MAC-I authentication is required. This approach 
has the same drawback as the previous one, i.e. between connections each 

15 party must maintain state information, which requires the use of a large da- 
tabase in the network. 

By way of example. Figure 1 illustrates the computation of a mes- 
sage authentication code in the UTRAN (UMTS Terrestrial Radio Access 
Network), which is a wideband multiple access radio network currently being 

20 specified in the 3GPP (Third Generation Partnership Project). The length of 
the MAC-I used in UTRAN is 32 bits. 

Block 100 represents the UMTS integrity algorithm for generating 
the message authentication code. The UMTS integrity algorithm used in 
block 100 is a one-way cryptographic function for calculating the 32 bit Mes- 

25 sage Authentication Code (MAC-I) based on the five input parameters shown 
in Fig 1 . A one-way function makes it impossible to derive the unknown input 
parameters from a MAC-I, even If all but one input parameter are known. 

The input parameters for calculating the MAC-1 20 are: the actual 
signaling message 10 (after encoding) to be sent, a secret integrity key 12, a 

30 number COUNT-I value 14 for the message to be Integrity protected, a value 
indicating the direction of transmission 16, (i.e. whether the message is sent 
in uplink or downlink direction), and a random number 18 (FRESH) gener- 
ated by the network. The COUNT-I value consists of a hyper frame number 
HFN and the message sequence number SN. The computing block 100 

35 calculates the message authentication code by applying the afore-mentioned 
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parameters to the integrity aigorltlim, which is called the f9 algorithm In 
3GPP Release'99 specifications. 

FIG. 2 illustrates a typical message to be sent over a radio inter- 
face. The message is a layer N protocol data unit (PDU) 200. which is 
5 transferred as a payload 30 in a layer N-1 PDU 201 . In the present example, 
layer N represents the Radio Resource Control (RRC) protocol in the radio 
Interface and layer N-1 represents the Radio Link Control (RLC) layer. The 
layer N-1 PDU normally has a fixed size, which depends on the physical 
layer (the lowest layer, not visible in FIG 2) the channel type used and on 
10 other parameters, e.g. modulation, channel coding, interleaving. If layer N 
PDUs are not exactly the size of the payload 30 offered by layer N-1 as is 
normally the case, layer N-1 can utilize functions like segmentation, concate- 
nation, and padding to make layer N-1 PDUs a fixed size. 

In the example discussed herein, a layer N PDU consisting of the 
15 actual signaling data 22 and the Integrity Check Info is discussed. The Integ- 
rity Check Info consists of the 32 bit MAC-I 26 and the message sequence 
number SN 24, which is needed at the peer end for the recalculation of 
MAC-I. The total length of the message 200 is then a combination of the 
signaling bits and the Integrity Check Info bits. 
20 At the receiving end the message is received including the sig- 

naling data part and the Integrity Check Info (which comprises the message 
sequence number SN and the 32-bit MAC-I). The signaling data together 
with the Integrity Check Info (ie the secret integrity the COUNT-I value, the 
direction of transmission, and the random number (FRESH)), are processed 
25 in a computing block, for example a function like the UTRAN f9 function, with 
a fixed function. A thus generated received computed message authentica- 
tion code XMAC-I is then compared with the message authentication code 
MAC-I received in the transmitted message. If the two codes match (ie 
XMAC-I matches MAC-I), the recipient can trust that the message Is intact, 
30 and the recipient then accepts the message. Othenwise, the message is 
discarded. 

The frame dependent COUNT-I number is actually the sum of a 
locally generated and incremented frame number HFN (Hyper Frame Num- 
ber), which is added to the message sequence number, for example 
35 RRC_SN, and included In the message. The HFN is incremented each time 
SN reaches its maximum value (SN is nomnally very short, e.g. 4 bits). 
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As mentioned hereinabove the transmitted block (layer N-1 PDU) 
normally has a fixed length. However, it may be that the signaling data bits 
together with the Integrity Check Info require more space than that provided 
in one layer N-1 PDU payload. One known way to deal with this problem is 
5 to segment the signaling message. 

In segmentation a signaling message, which is too long to fit in a 
single layer N-1 block, is passed on to a lower layer, where it is split up into 
two blocks (two layer N-1 PDUs), each with an appropriate layer N-1 header. 
Two blocks is just an example here, naturally a larger message may require 

10 even more than two blocks. If the second layer N-1 PDU is not totally filled 
with the layer N data, padding bits are inserted. At the receiving, end before 
transferring to a higher layer, the two layer N-1 payloads are reassembled 
into one layer N PDU. To a person skilled in the art, it is immediately obvious 
that the use of padding bits is a potential waste of resources. 

15 TDMA systems, for example, have a limited radio block size, 

whereby a message Including the full message authentication code does not 
necessarily fit into one radio block. This leads to the difficulty that the mes- 
sage has either to be sent without the MAC-I or in one or more additional 
segments. 

20 In addition, there are certain time critical messages, for example, 

handover messages, which must be sent in one radio block only. Generally, 
segmentation is not desirable, because it wastes radio resources and slows 
down the signaling procedure unnecessarily. 

One way to solve the above problem is to make the length of the 

25 message authentication code shorter than 32 bits. It has been proposed that 
such a message should include a field that defines the length of the mes- 
sage authentication code, a two-bit identifier, for example. This identifier 
allows certain discrete values: 8, 16, 24 and 32. This solution still has some 
problems. First, the identifier always takes two extra bits from the length of 

30 the message. Second, the discrete values are not flexible, and in some 
cases this can lead to the same problem as above, i.e. segmentation is 
needed for certain messages. 

A particularly advantageous technique for addressing the above 
stated problems is disclosed in Finnish patent application number . 

35 FI20002453. This discloses a technique that allows the transmission of a 
message in a single lower layer data block even when the length of the mes- 
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sage including the integrity check Info exceeds the length of the lower layer 
data block. 

In all current known solutions, each message is authenticated 
separately. Each message contains a sequence number of the protocol it 
5 belongs to. Hence a binding between different steps in the existing solutions 
is achieved through the sequence number. The drawback to existing solu- 
tions is that at each step a 32-bit IVIAC is transmitted which takes a signifi- 
cant part of the signaling bandwidth. 

It Is therefore an object to the present invention to provide an im- 
1 0 proved technique for taking the integrity of messages. 

SUMMARY OF THE INVENTION 

In accordance with the present invention there is provided a method of pro- 
viding message authentication in a communication system comprising the 
steps of: transmitting a first message from a first device to a second device; 

15 transmitting a second message from the second device to the first device, 
the second message including a message authentication code determined 
using said first and second messages; transmitting a third message from the 
first device to the second device, the third messages including a message 
authentication code determined using the third message. 

20 In order to minimize the risk of 'replay attacks', the sequence numbers 
should preferably be maintained in the protocol. This is particulariy important 
if the messages are short or otherwise small in number. 
The method may further comprise the step of storing the first message in the 
first device. 

25 The method may further comprise the steps of: responsive to receipt of the 
second message, determining an expected message authentication code 
using said first and second messages; and comparing the expected mes- 
sage authentication code to the received message authentication code. The 
method may further comprise the step of discarding the second message If 

30 the expected message authentication code does not match the received 
message authentication code. 

The method may further comprise the steps of: responsive to receipt of the 
third message, determining an expected message authentication code using 
said third message; and comparing the expected message authentication 
35 code to the received message authentication code. The method may further 
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comprise the step of discarding the third message if the expected message 
authentication code does not match the received message authentication 
code. 

The third message may include a message authentication code determined 
5 using the third message and the second message. 

The method may further comprise the step of storing the second message in 
the second device. 

The method may further comprise the steps of: responsive to receipt of the 
third message, determining an expected message authentication code using 

1 0 said third message and said second message; and comparing the expected 
message authentication code to the received message authentication code, 
The method according to claim 9 may further comprise the step of discarding 
the third message If the expected message authentication code does not 
match the received message authentication code. 

1 5 The third message may include a message authentication code determined 
using the third message, the second message, and the first message. 
The method may further comprise the step of storing said first message in 
the second device. 

The method may further comprise the steps of: responsive to receipt of the 
20 third message, determining an expected message authentication code using 
said third message, said second message, and said first message; and 
comparing the expected message authentication code to the received mes- 
sage authentication code. The method may further comprise the step of 
discarding the third message if the expected message authentication code 
25 does not match the received message authentication code. 

The invention may thus advantageously reduce the bandwidth used for 
authentication. In a multi-step protocol, the invention provides for the mes- 
sages exchanged at different steps to be grouped together for message 
authentication code computations. A message is saved by the sending party 
30 for subsequent verification at a later step. 

The number of required message authentication code computations and 
transmissions may be reduced to two independently of the number of steps 
in the authentication procedure. 

In three step signaling procedures, there is thus no need for a message 
35 authentication code to be computed in the first step. 
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The invention is further advantageously applicable to procedures containing 
more than three messages. AH communications that occur between two 
parties in various steps may be authenticated by the communicating parties 
in the last two steps of the protocol. 
5 The first and second devices are preferably elements of a mobile communi- 
cation system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be described more closely with reference to the 
accompanying drawings, in which 

Figure 1 depicts the computation of a message authentication code; 
Figure 2 shows the contents of a message; 
Figure 3 illustrates a first embodiment of the present invention; 
Figure 4 illustrates a second embodiment of the present invention; 
Figure 5 depicts the creation of a message according to a preferred imple- 
mentation; 

Figure 6 is a flow chart showing the creation of a message in the GERAN 
system, and 

Figure 7 is a flow chart of actions at the receiving end. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

The invention is described herein by way of reference to particular 
non-limiting examples, and with particular reference to a GERAN system. 
The GERAN is specified by the Third Generation Partnership Project 
25 (3GPP). GERAN is an evolution of the GSM-system (Global System for 
Mobile Communication), the TDMA/1 36-system (Time Division Multiple Ac- 
cess System), and the EDGE-system. GERAN has no integrity protection of 
its own. Implementation of the same integrity algorithms used in UTRAN is 
suggested for a radio system using the GPRS/EDGE-radio connection net- 
30 work GERAN. This leads to certain significant problems, especially the 
problem of message segmentation. 

The present invention can be advantageously used for Imple- 
menting an integrity algorithm in the GERAN system, and the present inven- 
tion is described herein with reference to example Implementations in such a 
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system. However, the invention is not limited in its application to such a 
system. 

Radio interface protocols are needed to set up, reconfigure, and 
release Radio Bearer services. The protocol layers above the physical layer 
5 are called the data link layer (layer 2) and the network layer (layer 3). The 
control plane layer 2 contains two sub-layers: Medium Access Control (MAC) 
protocol and Radio Link Control (RLC) protocol. Layer 3 consists of one 
protocol, called Radio Recourse Control (RRC), which belongs to the control 
plane. The channels offered by the physical layer to the MAC layer are called 
10 logical channels. It shall be appreciated that the term "logical channel' can be 
used for other purposes in other systems. For example, in the UTRAN the 
term logical channel referes to a channel offered by the MAC layer to higher 
layers. 

All higher layer signaling (mobility management, call control, ses- 
15 sion management, etc.) is encapsulated into RRC messages for transmis- 
sion over the radio interface. 

The following provides a description of integrity protection for a 
message to be sent over a radio link. 

Referring to Figure 3, a first embodiment of the present invention is 
20 described. For the purpose of this illustrative example, it is assumed that 
messages are being exchanged between the mobile station 40 and a net- 
work 42. It is assumed that the mobile station 40 initiates the exchanged 
messages. 

The mobile station 40 constructs a message for transmission in the 
25 normal way in accordance with standard procedures. Prior to transmitting 
the message, as indicated by step 50, the mobile station 40 stores the initial 
message, labeled message_1 , in its memory. As indicated by arrow 44, 
message_1 is then transmitted from the mobile station 40 to network 42. In 
accordance with the present invention, the first message Is sent without a 
30 message authentication code. The network 42 receives the first message 
from the mobile station, and prepares a second message, message_2, for 
transmission back to the mobile station 40. In addition, in a step 52 the 
network 42 calculates a first message authentication code, MACJ_1 , using 
both the first message as received by the mobile station and the second 
35 message which it is to transmit to the mobile station. Thus the message 
authentication code to be transmitted with the second message is based on 
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the combination of both the first and second messages. As indicated by 
arrow 46, the network 42 then transmits a second niessage, message_2, 
with the message authentication code MACJ_1 . 

Using the received second message, message_2, and the stored 
5 first message, message_1, the mobile station 40 in a step 54 calculates the 
expected message authentication code XMAC_1_1 . If XMAC_I_1 is identical 
to MAC_I_1 , then the mobile station 40 continues with message transmis- 
sion. Otherwise the received message message_2 is discarded. 

In this embodiment of the invention, the mobile station 40 prepares 

1 0 to transmit a third message message_3 to the network 42. In the step 56 the 
mobile station 40 prepares a second message authentication code MAC_I_2 
using the content of the third message message_3. As represented by ar- 
row 58, the third message message_3 is transmitted to the network 42 to- 
gether with the second message authentication code MAC_I_2. 

15 The network 42 then calculates the expected message authentica- 

tion code XMACJ_2 using the third message message_3 in step 58, and in 
the normal way compares this to the transmitted authentication code 
MAC_I_2. 

Whilst in Figure 3 the three messages are identified as message_1 . 
20 message_2 and message_3, in actual signaling procedures they may be 
named, for example, XXX_request, XXX_command, XXX_complete (or 
"confirm"). 

Thus in accordance with the first embodiment of the invention, the 
message authentication code is left out of the first' message. The message 

25 authentication code for the second message is calculated over the first and 
second messages, although the first message is not returned to the sender. 
The third message is integrity protected "nonnally", with a message authenti- 
cation code calculated over the third message itself. This technique ensures 
that the procedure cannot be used illegally by an Intruder, even if the first 

30 message is not integrity protected. 

Refenring to Figure 4, the second embodiment of the present Inven- 
tion Is now described. Where appropriate, the same reference numerals as 
used in Figure 3 are used to refer to identical steps or procedures. The 
embodiment of the Invention described with reference to Figure 4 is suitable 

35 for signaling procedures normally having either two or three messages. 
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As in the embodiment described hereinabove with reference to Fig- 
ure 3, the mobile station 40 prepares a first message message_1 for trans- 
mission to the networlc 42, and prior to transmitting it, as represented by 
arrow 44, stores it in a memory as represented by step 50. In step 52, the 
5 network 42 calculates a first message authentication code MAC_L1 using 
both the first message and the second message. In an additional step 53, 
the network 42 saves the second message message_2 Into Its memory be- 
fore transmission. As In the embodiment of Figure 3, the network 42 trans- 
mits the second message message_2 together with the first message 
10 authentication code MACJ„1 as indicated by arrow 46 to the mobile station 
40. 

In step 54, as in the embodiment of Figure 3, the mobile station 40 
calculates the expected message authentication code XMAC_L1 using both 
the received second message and the stored first message. If the expected 

15 message authentication code XMACJ_1 is identical to the received mes- 
sage authentication code MACJ_1, then the procedure is continued with. 

In this embodiment of the present invention, the mobile station 40 
then calculates in step 55 a second message authentication code MACJ_2 
using both the third message to be sent, message_3, and the received sec- 

20 ond message, message_2. The mobile station 40 then transmits, as indi- 
cated by arrow 48, the third message, message_3, together with the mes- 
sage authentication code MAC__I_2. 

The network 42 then calculates the expected second message 
authentication code XMACJ_2 using both the stored second message mes- 

25 sage_2 and the received third message message_3 in step 59. 

Thus, in common with the first embodiment described hereinabove 
with reference to Figure 3, the second embodiment as described with refer- 
ence to Figure 4 similariy does not include any message authentication code 
in the first transmitted message. The difference of the second embodiment 

30 compared to the first embodiment is that the third message contains a mes- 
sage authentication code calculated over both the second and third mes- 
sages, whereas in the first embodiment the message authentication code is 
calculated over only the third message. 

The technique of Figure 4 may be more advantageous in situations 

35 where the third message is added only for this purpose, ie it does not contain 
any actual information but is merely an acknowledgement message and is 
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thus very short. From a security viewpoint, the calculation of the integrity 
check sum over a longer message is beneficial. 

The addition of a third message may be more preferable than seg- 
mentation of the first message, because the segmentation solution necessi- 
5 tates additional acknowledgement (on data link layer level). 

In a third embodiment of the present invention, the message 
authentication code transmitted with the third message is calculated over all 
three messages, ie message_1, message_2 and message_3. The advan- 
tage of this embodiment is that each check sum protects the maximum 

10 amount of the data communicated in the procedure. Thus, this variation 
excludes the possibility of an attack where a "man in the middle" replaces the 
first message with another one and modifies the message authentication 
code in the second message accordingly. Such an attack could only be 
successful If the attacker is able to modify the check sum con-ectly. There 

15 are two possible ways to do this: 1) the replay of an earlier message authen- 
tication code; or 2) pure guessing. 

The first way is only possible if the counter number repeats, which 
means the same integrity key has been in use for too long. The possibility of 
the second way being successful is a very low probability. However, if the 

20 message authentication code of the second message is not a full 32-bits 
long, the probability of the guessing attack becomes higher. 

If the "man in the middle" is to have any chance of making a suc- 
cessful attack when the third embodiment of the invention is in use, then it is 
necessary for either 1) or 2) to be succeeded twice, which is much more 

25 difficult 

The present invention can particularly advantageously be used in 
combination with the technique described in Finnish patent application num- 
ber Fl 120002453. Such a technique is described hereinbelow. It should be 
noted that the techniques described hereinbelow may only be utilized in 

30 steps where a message authentication code is being generated, and hence 
would not be used in accordance with the invention in relation to the genera- 
tion and transmission of the first message. It should also be noted that other 
techniques may also be used. 

Figure 5 illustrates a situation where a signaling message 500 Is to 

35 be sent in a secure manner over a lower layer radio link in one fixed length 
radio block, which can be a TDMA block, for example, without segmentation. 
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The maximum block size allowed by the lower layer data block 501 is indi- 
cated by dotted lines in the figure. The signaling message without the Integ- 
rity Check Info (ICI) Is in the illustrated situation shorter than the said maxi- 
mum block size. This leads to a situation where the data to be sent either 
5 has to be segmented or sent without the message authentication code. Nei- 
ther of these altematives is acceptable. 

In order for the data to be sent in a sufficiently secure manner 
over a radio link, the computed message authentication code should be 
appended to it However, it must be shortened in a predefined way (de- 

10 scribed in detail below). This truncated message authentication code dimin- 
ishes the reliability of the integrity protection to some degree but still provides 
sufficient protection for the message. It should be noted, that the sequential 
number SN needed to form the COUNT-! parameter cannot be truncated. 
The message authentication code may be computed in the usual way in the 

15 device concerned and the MAC-I added with the message sequence number 
to the encoded message to form the actual PDU. Then the length of the 
message (without the Integrity Check Info) and/or the length of the PDU can 
be examined as follows. 

i) If the length of the message is longer than the length of the lower layer 
20 data block, the PDU is segmented into two or more data blocks as in prior 

art. 

ii) If the length of the PDU is shorter than the length of the lower layer data 
block, the PDU is placed into said lower layer data block and the rest of the 
block is filled with padding bits (normally by the lower layer itself). 

25 iii) If the length of the PDU is longer than the length of the lower layer data 
block but the extra bits are less than the size of the MAC-I. then the com- 
puted message authentication code is truncated so that the truncated PDU 
fits into one layer N-1 data block. However, truncation of the message 
authentication code diminishes the security of the message exchange. 

30 Therefore, the number of bits the MAC-I is allowed to be truncated by is 
limited to a certain maximum value. I.e. the truncated message authentica- 
tion code has a certain minimum value. 

Thereafter, the truncated PDU is sent via a radio interface to the receiving 
end.. 

35 At the receiving end the integrity is examined of the PDU received. First, the 
part including the signaling bits and the part including the Integrity Check Info 
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are separated. Then a message authentication code is recomputed based 
on exactly the same algorithm and using the same parameters as were used 
at the transmitting end. The message authentication code of the received 
message is then compared with the recomputed authentication code. 

5 FIG. 6 shows as a flowchart a more detailed example of one Im- 

plementation of the method according to the Invention from the point of view 
of the transmitting end. 

At stage 600 a time critical RRC message is to be sent through a 
radio interface, for example from the network to a mobile. 

Most signaling messages sent between a mobile station MS and 
the network, for example, must be integrity protected. Examples of such 
messages are RRC, MM, CC, GMM, and SM messages. Integrity protection 
is applied at the RRC layer, both in the mobile station and in the network. 

Integrity protection is usually perfomned for all RRC (Radio Re- 
15 course Control) messages, with some exceptions. These exceptions can be: 

1 . messages that are assigned to more than one recipient, 
-messages that have been sent before integrity keys were created 
for the connection, 

2. frequently repeated messages, including information which does 
20 not need integrity protection. 

The message Is encoded according to the specified message 
transfer syntax at stage 601. The encoded message (bit string) is called here 
E. 

A 32-bit message authentication code MAC-i, which is to be 
25 added to the encoded message, is calculated at stage 602. 

The message authentication code not only depend on the en- 
coded message but also on several other parameters. The following input 
parameters are needed for calculation of the integrity algorithm: the encoded 
message, the 4-bit sequence number SN, the 28-bit hyper-frame number 
30 HFN, the 32-bit random number FRESH, the 1-bit direction identifier DIR. 
and the most important parameter - thel 28-bit integrity key IK. The short 
sequence number SN and the long sequence number HFN together com- 
pose the serial integrity sequence number COUNT-I. 

When the message authentication code is computed using the 
35 UMTS integrity algorithm and the above parameters, it is guaranteed that no 
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one other than the actual sender can add the correct MAC-I code to the 
signaling message. COUNT-I, for example, prevents the same message 
from being sent repeatedly. However, if the same signaling message for 
some reason or other is to be sent repeatedly, the MAC-I code differs from 
5 the MAC-I code that was in the previously sent signaling message. The aim 
of that is to protect the message as strongly as possible against eavesdrop- 
pers and other fraudulent users, 

Due to the fact that a TDM A radio block has a fixed length, the 
length of the message has to be checked to avoid segmentation of the mes- 
10 sage. The RRC layer makes a decision as to whether the segmentation of 
the message concerned is to be allowed or not. 

At stage 603 the total length of the signaling message to be sent 
without the message authentication code is calculated using the following 
formula: 

15 

X = max_size - sizeof(E) - si2eof(RRC_SN) 

In the above formula max^size is the maximum size (in bits) of a 
RRC message that can be sent in one radio block (i.e. there is no need for 

20 segmentation). Sizeof(E) is the size (in bits) of the encoded message and 
sizeof(RRC_ SN) is the size of the RRC sequence number, a 4-bit working 
assumption. X defines the length (in bits) of the rest of the fixed length mes- 
sage, which is still left after the minimum number of bits are reserved for the 
message authentication code, the untruncated MAC-I size may be different. 

25 Next, at stage 604, a comparison is made to ascertain whether the 

calculated X is between values 0 and min_MACIJen, where the latter value 
is the minimum allowed length for the message authentication code. This 
minimum length is a predefined value, which can be either the same for all 
messages or even a message type specific value. It is dear that the smaller 

30 the value, the weaker the protection. So It is obvious that a minimum length 
must be determined so that the message can be sent with adequate security. 

If the answer after said comparison is YES, this means that the 
message authentication code does not fit with the signaling message to be 
sent in one radio block. In other words, the space left in one radio block is 

35 too short even for a shortened message authentication code after the sig- 
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naling message is put into the block. If this is the case, the system protocol 
defines 605 as the next action to be earned out. 

If the answer after comparison is NO, the next step Is to compare 
whether X is between values min_MACIJen and 32, stage 606. 
5 If X is between those values, i.e. if the answer after the compari- 

son In stage 604 is YES, then X bits of the message authentication code with 
the RRC_ SN are added to the encoded message, stage 607. The sequence, 
number RRC_SN is needed for integrity protection, that is, for calculation of 
the message authentication code at the receiving end. Note that the MAC-I 
10 size is also 32 bits in the UTRAN system. In some other systems, the 'nor- 
mal" MAC-I size may be something different. 

The length of the message authentication code is shortened in a 
predefined way. Thus, the size of the message authentication code trans- 
mitted over the radio path depends dynamically on the size of each encoded 
1 5 message, not on the type of the message. 

The decisions are made at the RRC layer as to the minimum 
message authentication code size and as to when the size of the said code 
may be shortened. In some cases the RRC layer can make the decision that 
the message authentication code is not to be shortened even though this 
20 would have been possible. Such cases might occur when strong protection is 
demanded for a message. 

The next step 611 is to send the message including the integrity 
protection info (E + MAC-I + RRC_SN) to the lower layers for transmission 
over the radio interface to the mobile station. 
25 If the answer in the above comparison 604 is NO, a final compari- 

son is made as to whether the value of X is greater than 31 , stage 608. If the 
answer is YES, this means that neither shortening nor segmentation is 
needed. Now the whole message authentication code and the RRC_SN are 
appended to the encoded message E, stage 609. The next step is stage 
30 611. 

If the answer to the comparison at stage 608 is NO, i.e. if X is 
smaller than 0, which means that the size of the encoded message sizeof(E) 
is greater than the maximum size of the RRC message max_size, then two 
different altematives A and B, are possible, at stage 61 0: 
35 1 . add the entire MAC-I (+RRC_SN) to the message; 
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2. set sizeof(E) = (sizeof(E) - max_size) and rerun the previous 
steps. 

Which of the two above alternatives is selected depends on the 
protocol according to the system. 
5 Alternative A means that the whole message authentication code 

with the sequence number RRC_SN is added to the block, since the mes- 
sage has to be segmented anyway. Thus with this alternative, it is not Im- 
portant whether adding Integrity Protection Info causes additional segmenta- 
tion or not- 

10 In alternative B, the attempt is made to avoid the additional seg- 

mentation caused by the addition of Integrity Check Info, Thus the sizeof(E) 
is set one full data block shorter than what was given in stage 601, and the 
truncation algorithm for the MAC-I is rerun starting from step 603. 

FIG. 7 shows as a flowchart an example of one implementation of 

15 the method according to the invention from the point of view of the receiving 
end. 

At stage 700 the receiving end gets a Service Data Unit (SDU) 
comprising the signaling data M from the lower layers. It is assumed here 
that this message is the same as in the previous example in FIG, 6. The next 

20 step is that the part including signaling data bits and the part including the 
Integrity Check Info MAC-I (the message authentication code with the se- 
quence number the RRC_SN) are separated and a message authentication 
code with RRC sequence number RRC_ SN is decoded in stage 701 . The 
actual message (signaling data) can still be stored as an encoded bit string 

25 at this point. 

In prior art systems the message received is discarded Immediately 
if the received and the recomputed message authentication codes do not 
match- But according to the described embodiment of the invention, the 
receiving end first examines the length of the message authentication code 

30 and, depending on the result, it then decides, if and how the message is to 
be processed further. 

For example, if the receiving end finds that the message authenti- 
cation code received is shorter than it should be, it may assume that the 
code has been truncated. Instead of n bits the truncated code comprises m 

35 bits. If the truncation exceeds the predetermined maximum amount known 
by the receiving end, the message is discarded. If tmncation does not ex- 
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ceed the predetermined maximum amount as known by the receiving end, 
the bits of the truncated message authentication code are compared bit-by- 
bit to the bits of the recomputed authentication code of full length. When the 
m bits of the truncated message authentication code match the correspond- 
5 ing bits of the recomputed message authentication code, the integrity check 
of the message received is passed. 

The length of the message authentication code of the message 
received is examined at stages 702 and 706. In addition, the length of the 
entire message (including the signaling data and the integrity check info) 
10 received is also examined at stage 704. 

At stage 702 a check is made as to whether the length of the 
MAC-I is 'normar, in this example 32 bits. If YES (the answer to stage 702 is 
NO), the flow proceeds to stage 703, where the message is processed in the 
nonnai way. The message authentication code is checked, the message is 

15 decoded, etc. using the same algorithm and parameters as were used at the 
transmitting end. 

Provided that stage 702 yields the YES alternative, meaning that 
the MAC-I has been truncated, a check is made as to whether the length of 
the message is a multiple of the max_size (sizeof(M) mod max_size == 0), 

20 justifying the MAC-I truncation. A NO alternative yields a protocol en^or, for 
which reason the message received is discarded 705. 

A YES answer after stage 704 leads to stage 706, when a com- 
parison is made as to whether the length of the message authentication code 
is greater than or equal to the minimum allowed MAC-I length 

25 (min_MACIJen). A NO alternative yields a protocol error, for which reason 
the received message is discarded 707. If the length is greater than or equal 
to the minimum value, the transmitting end may have shortened the MAC-I 
code in the correct way. With the integrity key and all the other needed pa- 
rameters, the expected message authentication code XM; ' I is calculated 

30 708, using the samr- algorithm as for the transmitting en^ "he calculated 
XMAC-I has to be trc-i icated in order to compare its size wiin the size of the 
transmitted MAC-I, stage 709. If the truncated XMAC-I does not correspond 
to the transmitted truncated MAC-I 710, an integrity enror is found and the 
received message is discarded 711. If the result of the comparison is posi- 

35 tive, the message is decoded 712. The final check 713 is made after decod- 
ing the actual signaling data 712. The final check is to find out whether there 
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are some padding bits in the received message. Since the MAC-I has been 
truncated due to message size, no padding bits are allowed (since the pad- 
ding bits should have been used for the MAC-I). The Integrity check is OK 
whenever no RRC padding bits are found 713, I.e. It is then ensured that the 
5 message has been sent from the authorized party 715. Otherwise, a protocol 
error is found and the message is discarded, stage 714. 

The above defined preferred technique for generation of the mes- 
sage authentication code may be used in the embodiments of the present 
invention at those steps where a message authentication code is generated. 

10 An implementation and embodiment of the present invention has 

been explained above with some examples. However, it Is understood that 
the Invention Is not restricted to the details of the above embodiment and 
that numerous changes and modifications can be made by those skilled In 
the art without departing from the characteristic features of the invention. The 

15 embodiment described is to be considered Illustrative but not restrictive. 
Therefore, the invention should be limited only by the attached claims. Thus, 
alternative implementations defined by the claims, as well as equivalent 
implementations, are included in the scope of the invention. 

For example, instead of at the RRC layer the decision concerning 

20 the MAC-1 size can be made at some other layer, e.g. the RLC layer. In that 
case, the RLC must know whether segmentation of the message(s) in the 
transmission buffer is to be allowed or not. 

The protocol layers from top to bottom may be, for example, RRC, 
LLC (Logical Link Control), LAPDm (Link Access Protocol on the Dm chan- 

25 nel), PDCP (Packet Data Convergence Protocol), RLC, MAC (Medium Ac- 
cess Control Protocol), and PHY (Physical Layer) 

In addition, the minimum value, which Is set at mln_MACIJen 
might also depend on the signaling message used. The grouping of signaling 
messages into different min_MACIJen categories can be carried out either 

30 simply according to the message type. Grouping can be based on other 
factors as well, such as on whether the message Is so that for critical signal- 
ing messages the value is greater than for non-crltlcal signaling messages. 
For some non-critical messages the min__MACMen could be set as low as 8 
bits, for example. 
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Utilised in combination with the techniques described with refer- 
ence to Figures 5 to 7 the present invention may allow, In certain situations, 
a longer MAC-I, thereby further improving integrity. 

The present invention is independent of the length of the message 
5 authentication code. Such code may be longer or shorter than 32 bits. The 
length may also differ between messages in one procedure. 

It should also be noted that although this application is made only 
from the signaling standpoint, integrity protection can also be applied in 
some systems to the user plane data. The same principles and methods 
10 described in this application are applicable also for user plane data packets, 
although the actual protocol layers performing the integrity protection, and 
the message authentication code truncation would then be different. 

15 
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Claims 

1. A method of providing message authentication in a communication sys- 
tem comprising the steps of: 

transmitting a first message from a first device to a second device; 
5 transmitting a second message from the second device to the first device, 
the second message including a message authentication code deter- 
mined using said first and second messages; 

transmitting a third message from the first device to the second device, 
the third messages including a message authentication code determined 
1 0 using the third message. 

2. A method according to claim 1, further comprising the step of storing the 
first message in the first device. 

3. A method according to claim 1 or claim 2 further comprising the steps of: 
responsive to receipt of the second message, determining an expected 

15 message authentication code using said first and second messages; and 
comparing the expected message authentication code to the received 
message authentication code. 

4. A method according to claim 3 further comprising the step of discarding 
the second message if the expected message authentication code does 

20 not match the received message authentication code. 

5. A method according to any one of claims 1 to 4 further comprising the 
steps of: 

responsive to receipt of the third message, determining an expected 
message authentication code using said third message; and 
25 comparing the expected message authentication code to the received 
message authentication code. 

6. A method according to claim 5 further comprising the step of discarding 
the third message if the expected message authentication code does not 
match the received message authentication code. 

30 7. A method according to ariy one of claims 1 to 6, wherein the third mes- 
sage includes a message authentication code determined using the third 
message and the second message. 
8, A method according to claim 7, further comprising the step of storing the 
second message in the second device. 
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9. A method according to claim 7 or claim 8, further comprising the steps of: 
responsive to receipt of the third message, detemnining an expected 
message authentication code using said third message and said second 

message; and 

5 comparing the expected message authentication code to the received 
message authentication code. 

10. A method according to claim 9 further comprising the step of discarding 
the third message if the expected message authentication code does not 
match the received message authentication code. 

10 1 1. A method according to any one of claims 1 to 10, wherein the third mes- 
sage includes a message authentication determined using the third mes- 
sage, the second message, and the first message. 
12. A method according to claim 11, further comprising the step of storing 
said first message in the second device. . 

15 13. A method according to claim 1 1 or claim 12, further comprising the steps 
of: 

responsive to receipt of the third message, determining an expected 
message authentication code using said third message, said second 
message, and said first message; and 

20 comparing the expected message authentication code to the received 
message authentication code. 
14. A method according to claim 13 further comprising the step of discarding 
the third message if the expected message authentication code does not 
match the received message authentication code. 

25 15. A method according to any one of claims 1 to 14 wherein the first and 
second devices are elements of a mobile communication system. 
16. A method of providing message authentication in a communication sys- 
tem comprising transmitting a plurality of messages between a first de- 
vice and a second device, wherein a message includes a message 

30 authentication code determined using at least said message and another 
message includes a further message authentication code detennined 
using at least said other message, whereby the number of required mes- 
sage authentication code computations and transmissions may be re- 
duced to two independently of the number of steps of the authentication 

35 procedure. 
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17. A communication system for providing message authentication between 
two communicating devices, each communicating device having respec- 
tive transmitting and receiving means, and each communicating device 
having means for generating a message authentication code, comprising: 

5 In the first device, transmitting a first message from the second device; 

In the second device, transmitting a second message to the first device, 
the second message including a message authentication code deter- 
mined using said first and second messages; 

In the first device transmitting a third message to the second device, the 
10 third messages including a message authentication code detemrilned us- 
ing the third message. 

18. A communication system according to claim 17, further including, in the 
first device: 

responsive to receipt of the second message, determining an expected 
15 message authentication code using said first and second messages; and 
comparing the expected message authentication code to the received 
message authentication code. 

19. A communication system according to claim 17 wherein the second 
message is discarded if the expected message authentication code does 

20 not match the received message authentication code. 

20. A communication system according to any one of claims 17 to 19 further 
comprising, in the second device: 

responsive to receipt of the third message, determining an expected 
message authentication code using said third message; and 
25 comparing the expected message authentication code to the received 
message authentication code. 

21 . A communication system according to claim 20 wherein the third mes- 
sage is discarded if the expected message authentication code does not 
match the received message authentication code. 

30 22. A communication system according to any one of claims 17 to 21, 
wherein the first device generates the third message including a message 
authentication code determined using the third message and the second 
message. 

23. A communications system according to claim 22, wherein responsive to 
35 receipt of the third message, the second device determines an expected 
message authentication code using said third message and said second 
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message; and compares the expected message authentication code to 
the received message authentication code. 

24. A communications system according to claim 23 wherein the third mes- 
sage if the expected message authentication code does not match the 

5 received message authentication code. 

25. A communications system according to any one of claims 17 to 24 
wherein the third message generated by the first device includes a mes- 
sage authentication code detennlned using the third message, the sec- 
ond message, and the first message. 

10 26. A communication system according to claim 25 wherein responsive to 
receipt of the third message, the second device determines an expected 
message authentication code using said third message, said second 
message, and said first message; and compares the expected message 
authentication code to the received message authentication code. 

15 27. A communication system according to claim 26 wherein the second 
device discards the third message If the expected message authentica- 
tion code does not match the received message authentication code. 

28. A communication system according to any one of claims 17 to 27 
wherein the first and second devices are elements of a mobile communl- 

20 cation system. 

29. A communication system according to claim 28, wherein the first and 
second devices are one of a mobile tenninal and a network element. 

30. A communication system according to claim 28 or 29, wherein the mo- 
bile communication system comprises a GERAN system. 

25 
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